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Foreword 


This is Part 2 of the article on Computer-Assisted Translation (CAT) applications which have been 
recently made available by the Directorate-General for Translation (DGT) of the European 
Commission as free open source software (FOSS). 


[click here for Part 1] 


Unlike DGT-OmegaT and Tagwipe which can be downloaded and used straightway, the two 
applications presented in this Part 2 require some work to be “usable” outside DGT, especially 
TeamBase: 


> Teambase (Developer: Thomas Cordonnier): An application initially developed privately by 
Thomas Cordonnier (Silvestris/Cyclotis project) which is being used in DGT and further 
customized to satisfy DGTºs needs. 

> DGT-OmegaT Wizard (Developer: Elio Fedele): a full in-house DGT application to integrate 
DGT-OmegaT in DGT?s workflow, automating most of the project management operations. 


The project is managed by Fons De Vuyst, Head of the Operational Support Sector in DGT's 
Informatics Unit. 


The DGT-OmegaT Wizard can only be used in a Windows environment, while TeamBase can be used 
in any Java8-compliant platform (Windows, Linux, MacOS) and has plugins for OmegaT and SDL 
Trados Studio. 


For both applications, the source code and the executable version are published, but as-is, without 
express or implied warranties, and come without support. 


6. Teambase 


DGT-OmegaT web site 


Download DGT-OmegaT specific features | Teambase Wizard Documentation Contact us 
Home 
User logi 
feias Teambase 

Username * 
Teambase is an alternative way to share work in real time between OmegaT users, using a SQL database as in intermediate. The main 
advantage compared to using Git or Subversion is that there is no latency: each segment validated by you is immediately available for all 

Password * users connected to the same database; they do not have to wait for the next time you save, automatically or not. And of course you will 
immediately see other people's work the same way. Another advantage is that you are not required to share the entire project : Teambase can 
be used to share real-time work between projects related to the same thematic, such as two manuals related to the same software. Last but 

* Request new password not least, Teambase memories are shareable between various CAT tools, with some limitations but in real time. 

Log in 


Let's detail the second point. Git/Subversion modes in OmegaT work by sharing the entire project, including the files which are not 
supposed to change during the lifecycle of the project, such as source files and non-writable glossaries. Teambase instead, enables sharing 
the equivalent of one of the modifiable files: if you want to share several files, you have to create the same number of connections to the 
database (but the plugin will manage to open less physical connections if possible). So, you can share : 


1. One or more memories, as ifyou had TMX files in the tm/ directory ; 


2. One or more glossaries, as if you had files in the glossaries/ directory ; 
as actually inside Omega-T, one of these files can be the main glossary: if you set it to Teambase, you obtain a shared writable 
glossary ; 


3. The project-save memory 

4. Other-language project-save memories, i.e. what is in tmx2source directory 
For all ofthe four previous points, a new select query is done to the database each time you go to a new segment. Memories (1) can be 
accessed in read-only or in read-write mode, in the second case each modified segment is sent to the memory, but you can define rules to 
prevent some useless insertions. Project-save (3) connections are always read-write, and the read query is a synchronization, meaning that 


you receive all changes, based on date, not contents. Other langage projects (4) are read the same way, but not written. Finally, glossaries (2) 
are updated if, and only if, you did the connection as main glossary. 


Sometimes a translation job needs to be split among different translators either because it is too big or 
because it is urgent. When cutting a file in two or more parts and giving each part to a different 
translator, or assigning several related documents to different translators, it is not efficient and/or is 
more costly to ensure consistency across translations if the translators cannot access their colleagues' 
ongoing translation in real-time. 


OmegaT already provides a solution for this: the team project feature, based on tools normally 
designed for software development, namely Git and Subversion. But this solution has some 
disadvantages, such as the incompatibility with other CAT tools. 


So TeamBase was developed as an option to allow the sharing of project memories in real-time among 
translators using either DGT-OmegaT or SDL Trados Studio, something which is very important in 
DGTº?s working environment. And TeamBase is being improved with user feedback! 


So that translators outside DGT can have an idea of what TeamBase is all about, to assess if it is of 
any interest to them/their work — and worth the trouble! — we present below a concise comparison, 
as objective as we can make it, between TeamBase and other options we know about. 
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6.1. Client/server and TeamBase architecture 
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First, let's make a brief technical introduction to TeamBase client/server architecture. For detailed 
technical information on TeamBase and how to install and use it, see the DGT-OmegaT website”. 


Both OmegaT's team project and TeamBase are what is generally known as client-server architectures. 
In simple terms, that means that there is one computer called the "server", accessed only via the 
network (Internet or internal network), which stores the common data, and the users connect to the 
server via their own computer, called a "client". The server is generally unique and "serves" multiple 
projects and this way each project is shared by several users (see the illustration below). 


Project 3 


Each user with DGT-OmegaT installed on a computer is a potential "client". Usually it is necessary to 
download separately the server, have/find a computer in a network to install it (usually, but not 
necessarily, a computer using a Unix distribution), install the programs and configure them depending 
on how the relevant user/organization manages its projects. Inside DGT we have one server, but it is 
only available internally and can only be shared within the DGT environment. 


DO uÊ pero G3 
For use outside DGT, TeamBase can esa ici ed ARES 
be installed in any server which e Bs. E. 
fulfils its requirements. na RRACIO Mesteirtocas (EFA 
Its installation is not as no De 
straightforward as for the other 3 = aa <a. & 
applications presented in this article. rd TO re 2) 
Just have a look at this screenshot to post | [arm e Ro 
see its structure. E o ie A é | ing M jm 
But don't be scared! E ga BR o 
It can be done... with a little help 1f Re PANA E o: A “são 
necessary! Java NET 4 fe 


OmegaT API Trados API 
(improved) (as is) 


Of course that, after being installed on a server, TeamBase can be used — and the settings defined — 
directly with all the features and options available. 


In DGT, TeamBase memories are created via the DGT-OT Wizard making it much simpler and user- 
friendly than via the web-based creation interface... although not all the features and options will be 
available. Default settings are automatically defined without the user's intervention, in a background 
operation, when a connection to TeamBase is made. 


Doing the same with the public version of the DGT-OT Wizard, once TeamBase is installed in the 
user”s server, should work without problems if it does not need any authentication (it is just a matter of 
setting the correct URL in the configuration file). The use of TeamBase via the Wizard outside DGT is 
now under test (namely concerning its use with authenticated servers). 

6.2. Creating a project to be shared 


To create a project on the server it is necessary: 


1 — To have TeamBase installed, of course, and its settings defined. 
2 — To create an OmegaT project as usual. 


In this article we will, for simplicity's sake, use as an example a single-document project 
which is to be translated by 2 translators. But TeamBase can be as easily used for (large) 


multi-document projects. 


For detailed information, see the DGT-OmegaT website. 


6.3. TeamBase modes 


Teambase enables sharing the equivalent of one of the modifiable files: several files can be shared and 
the same number of connections to the database can be created. So it is possible to share: 


One or more memories, as if the translator had TMX files in the Ytm directory; 

One or more glossaries, as if the translator had files in the glossary folder; the main glossary 
can work as a shared writable glossary; 

3. The project save memory; 

4. Other-language project save memories, i.e. what is in ltmx2source folder; 


Nm 


The first option is generally known as Memory Mode, option 2 as Glossary Mode and options 3 and 
4 as Project Mode. 


Let's now see each mode in some detail. 
6.3.1. Project Mode 


In this mode, TeamBase is used as a substitution of the project save.tmx file: each time a translator 
validates the translation of a segment (even if s/he doesn"t save it, contrarily to OmegaT's project 
mode), the translation is sent to the database. In the other direction, other users will see the translated 
segment inserted in their project once they validate another segment. 


To use TeamBase, all translators must have a copy of the project, including the file 
project save.properties. When they open the project in OmegaT, they will see it displayed as usual. 


Let's see what happens when Translator 1 opens segment 5 while Translator 2 has segment 1 opened 
in the Editor. Here we selected nearby segments only to make the behaviour immediately visible: in 
real usage, users will probably be in another part of the document. 


Translator 1 translates segment 1 and validates it. At this moment, the translators do not see the same 
thing anymore: 


Editor - ARTICLE-FOLHA-FOSS-DGT-OT-PART2-Teambase-EN,docx Editor - ARTICLE-FOLHA-FOSS-DGT-OT-PART2-Teambase-EN.docx 
Teambase Teambase 


Sometimes a translation work has to be divided between more than one translator: either because it is too big, or because it Sometimes a translation work has to be divided between more than one translator: either because itis too big, or because itis 
is urgent. urgent 

<segment 0002 ** EMPTY ** > 
Cutting the file in two or more parts and giving each partto a different translator is more or less like working without translation 
<end segment> memories: you have less ways to ensure that the translations are coherent. 


'OmegaT already provides a solution for this: the team project feature, based on tools normally designed for development, actually 
Cutting the file in two or more parts and giving each part to a different translator is more or less like working without translation tontisinhrásioei 


memories: you have less ways to ensure that the translations are coherent 


But this solution has some disadvantages which we will progressively describe in this article. 


J[ f dl 
Omega already provides a solution for this: the team project feature, based on tools normally designed for development actualy| | comment 0005 ** EMPTY ** > 


Gitand Subversion. 


Butthis solution has some disadvantages which we will progressively describe in this article. <end segment> 


You may also find disadvantages in our solution: we do not say the contrary, if you have suggestions please do them and we will 
study whenever itis possible to make Teambase even better. You may also find disadvantages in our solution: we do not say the contrary, if you have suggestions please do them and we will 


study whenever itis possible to make Teambase even better. 
A! 
74 
Clients and servers 


At this point, synchronization has not yet been done for Translator 2: it will only be done when (s)he 
does something like opening another segment or validating a translation, as shown below. 


Editor - ARTICLE-FOLHA-FOSS-DGT-OT-PART2-Teambase-EN.docx Editor - ARTICLE-FOLHA-FOSS-DGT-OT-PART2-Teambase-EN.docx 
Teambase Teambase 
Sometimes a translation work has to be divided between more than one translator: either because it is too big, or bechus x 
isurgent. Sometimes a translation work has to be divided between more than one translator. either because itis too big, or because itjis 
<segment 0002 ** EMPTY ** > urgent. 
<end segment> 


Cutting the file in two or more parts and giving each partto a different translator is more or less like working without translatign 
memories: you have less ways to ensure that the translations are coherent 
Cutting the file in two or more parts and giving each partto a different translator is more or less like working without translafior ' 

memories: you have less ways to ensure that the translations are coherent OmegaT already provides a solution for this: the team project feature, based on tools normally designed for development, acjually 
Git and Subversion. 
OmegaT already provides a solution for this: the team project feature, based on tools normally designed for development, pctt 

Gitand Subversion. Mais cette solution a aussi des désavantages qui vont être progressivement décrits dans cet article. 
Butthis solution has some disadvantages which we will progressively describe in this article Vowimiay dias fd dissdvantáges ls our soludoa: we do notsa) lie Contraiy Iiyou ava sapgestioas please do fica midia 
You may also find disadvantages in our solution: we do not say the contrary, if you have suggestions please do them and je v | Will study whenever it is possible to make Teambase even better. 
study whenever itis possible to make Teambase even better. <segment 0006 ** EMPTY = > 


71 <end segment> 
Clients and servers 


74 


Clients and servers 


Now that Translator 2 has validated a segment, s/he also sees, on the top, the segment validated by 
Translator 1. In the other computer, nothing changed. But now lets see what happens when Translator 
1 again validates a segment: 


eos pipa ADE Ea asda Editor - ARTICLE-FOLHA-FOSS-DGT-OT-PART2-Teambase-EN.docx 


Teambase 
Teambase 
Paríois un travail de traduction doit être partagé entre plus dun traducteur : soit parce qu'il esttrop long, soit parce quil est Jroé 

Sometimes a translation work has to be divided between more than one translator: either because itis too big, or because tis 
Cutting the file in two or more parts and giving each part to a different translator is more or less like working without urgent. 
translation memories: you have less ways to ensure that the translations are coherent. 


<segment 0003 ** EMPTY ** > Cutting the file in two or more parts and giving each partto a different translator is more or less like working without translatjon 


<end segment memories: you have less ways to ensure that the translations are coherent. 


OmegaT already provides a solution for this: the team project feature, based on tools normally designed for development, aktually 
OmegaT already provides a solution for this: the team project feature, based on tools normally designed for development, aftu: | Git and Subversion. 
Gitand Subversion 
SO Mais cette solution a aussi des désavantages qui vont être progressivement décrits dans cet article. 
You may also find disadvantages in our solution: we do not say the contrary, if you have suggestions please do them and we w | You may also find disadvantages in our solution: we do not say the contrary, if you have suggestions please do them and we 
study whenever itis possible to make Teambase even better. will study whenever it is possible to make Teambase even better. 
<segment 0006 ** EMPTY = > 
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Clients and servers <end segment> 


A. 


Clients and servers 


This time, nothing changes on the Translator 2ºs screen. But look at the Translator 1ºs screen, on the 
left: once he has validated the translation for segment 2, s/he can also see the translation of segment 5, 
which has been validated by the other translator. 


Besides this, working with Teambase in Project Mode is virtually the same as working alone, the only 
noticeable difference being that each translator receives all the other translators' translated segments as 
soon as they are validated (either with Enter or by leaving the newly translated or modified segment 
in any other way). 


So translators sharing a project will work with OmegaT as usual, except that sometimes a new 
segment (for that translator) is displayed with a green background, something which in this case means 
that it has already been translated by a colleague sharing the project. 


For translators who are familiar with OmegaT's "team projects”, this should not be a surprise: in this 
mode as well, the translator also receives translations from other colleagues. The difference is in the 
frequency of the upgrade: for OmegaT's "team projects”, this occurs on every save, so every 3 
minutes, while for TeamBase it occurs immediately each time a segment is validated. 


TeamBase and team projects have differences, but the common point is that they act on request: when 
a translation is submitted, it is sent to the server, but the server does not inform other clients that there 


is a new segment — the other clients will receive the new segment only when they ask the server 
again, and that occurs when they open a new segment — whether they added a new translation or not. 
A pull-based service, where the server informs all its clients that there is a new segment, would be 
more complicated to develop... and not really necessary! 


One last point about the Project Mode: until now we have used it as a substitute for project save.tmx, 
but in the beginning of this section, we also said that it can be used as a substitute for tmx2source. If 
the properties file is placed in the tmx2source folder and named as, for example, FR.properties, then 
the result will appear in the Editor as if it came from the FR.tmx memory: 


OmegaT already provides a solution for this: Using a database instead of a TMX file makes sense 
FR: OmegaT propose déjã une solution pour cela: only if the other-language translator is working 
a DS EE simultaneously on that document: all segments 


validated by that other-language translator in OmegaT 
will be displayed, even if (s)he is still working on it. 


<end segment> 


6.3.2. Memory Mode 


In this mode the translators are basically sharing a translation memory (like a TMX, except that it is 
outside each translator's computer and can be in Read/Write mode). 


All features available for TMX files (including concordance if DGT-OmegaT version 3 is used) are 
valid for this memory, plus the fact that, in Write mode, it will also receive a copy of the segments 
that are being translated, making them immediately available for the translators connected to the same 
memory, as shown below. 


Editor - ARTICLE-FOLHA-FOSS-DGT-OT-PART2-Teambase-EN,docx 


eeregemrermerpemeee 


<Teambase - ARTICLE> 21111117 17:16 
Inthis mode, TeamBase is used as equivalent to a TMX file: Match: <66/69/75%> - Source: <---> - Translator: <«cordoth> 
<segment 0079** EMPTY * > by 


(1) > In this mode, TeamBase is used as a substitution to the 
<end segment> <tO>project save.tmxst1)> file: 
Dans ce mode, TeamBase est utilisé comme une alternative au fichier 
<tOl>project save.tmxstf/>: 
results appear in fuzzy matches pane. 


In this example, a segment was found in TeamBase which has a 66% match to the current one. So, it 
appears in the Fuzzy Matches pane, as if it came from a TMX file. 


But what happens if there is a 100% match in TeamBase? 


Editor - ARTICLE-FOLHA-FOSS-DGT-OT-PART2-Teambase-EN.docx 


> a a a <Teambase - ARTICLE> 21/11/17 17:16 
och ft e Match: <100/100/100%> - Source: <-> - Translator: <cordoth> 
<segment 0075 ** EMPTY * > 


| (1) > In this mode, TeamBase is used as a substitution to the 
<end segment> «<tO/>project save.tmx<t1/> file: 
Dans ce mode, TeamBase est utilisé comme une alternative au fichier 
<t0/>project save.tmx<t1/>: 


each'time you validate a translation itis sentto the database and available to other users. 


The result is the same: a score of 100% is displayed, but that's all — translation memories, such as 
TMX files or TeamBase in Memory Mode, are only given as information, they are not part of the 
project memory. That is the difference in Project Mode: a segment translated by one translator is 
equivalent to a segment translated by another translator. 


However, it may happen that, when a translator opens a segment, OmegaT automatically inserts 
something in it. In this case it means that the Insert the best fuzzy match is activated in the Editor 


behaviour menu. This feature has nothing to do with TeamBase: whether the translator is in Project 
Mode, Memory Mode or not at all connected to TeamBase, (s)he may see the same behaviour if the 
segment comes from a TMX or even from a similar segment present in the document being translated. 


In DGT-OmegaT, we decided to use a special colour (dark yellow background for fuzzy matches or 
dark green background for 100% matches) to make the distinction between Insert best fuzzy match 
and segments coming from the project memory (not to forget that, in Project Mode, TeamBase is the 
project memory). We hope that the colour makes it easier for translators to see the difference. 


But what happens now if Translator 1 validates this segment? 


In Project Mode, OmegaT would apply the same rule as for project save.tmx: either it is a default 
translation and it is replaced, or the translator creates an alternative translation, and unless the context 
(previous/next segments) is the same, both are kept by the server. 


In Memory Mode, things are not so strict and there are several options. The translator can choose to: 


- Keep all entries: cach segment is saved in TeamBase, even if a segment with identical source 
already existed; 

- Keep only last one: if a segment existed with the same source (strictly, including tags) then 
the new segment replaces the previous one; 

- Keep one entry per author: if the translator submits a segment which (s)he has already 
translated, the server will replace it; but if it was associated to another author, then both are 
kept. This is the option generally preferred inside DGT and which is configured by default in 
the Wizard; 

- Keep one entry per context: as in the Project Mode. 


This must be chosen when the TeamBase memory is created and cannot be changed later. However, 
other memories can be created in the same server with different parameters. In all cases, the 
parameters defined at creation time will be kept throughout the life of each of the memories. 


Memory Mode is useful when users are not really working on the same project, but on similar ones 
(two documents on the same subject, for example), as the Project Mode absolutely requires 100% 
matches. 


On the other hand, if both translators have the same document in the source folder and decide that each 
translator has his/her own part to translate, then Memory Mode is not appropriate, due to the fact that 
auto-insertion is not done in non-visited segments and features such as “generate translated 
documents” will produce the other part in the original language. 


Memory Mode is also useful if a translator working with DGT-OmegaT wants to share his/her work 
with others who are using SDL Trados Studio: due to differences in the way both tools store their 
context, their tags or their segmentation, there will be less 100% matches and more partial matches 
(even 1f the document to be translated is the same) compared to a full OmegaT setup in which all 
translators are working with DGT-OmegaT. So Project Mode cannot work in a heterogeneous 
environment. Concordance in this multi-tool setup will not be affected as long as tags are avoided in 
searches. 


Memory Mode also supports the notion of Inheritance, as in object-oriented programming. For 
example, let's say that the translator created a memory named "Agriculture" to share it with all 
translators working on projects on this subject. But at a certain point, some translators thought that the 
theme was too general and created another memory named "Cereal". 


With Inheritance, when a project is connected to "Cereal", all the segments are sent to this specific 
database, but translators connected to other children of " Agriculture”, for example "Meat", will also 


see, if they activated Inheritance, all the segments from " Agriculture" and all children, without writing 
anything to them. 


A general thing to remember is that, in TeamBase, more than one Memory Mode can be used in the 
same project simultaneously with one Teambase in the Project Mode. The only thing that must be 
avoided is to connect simultaneously in Project Mode and Memory Mode to the same TeamBase 
memory. 

6.3.3. Glossary Mode 
The Glossary Mode makes it possible to host in the server a shared version of the "writable glossary" 
provided by OmegaT: instead of it being in a file in the user computer, it is in the server and each time 


a new entry is added it is immediately available to other users. 


Glossary Mode has support for Inheritance, like for Memory Mode. 


7. DGT-OmegaT Wizard 


DGT has developed in-house a DGT-OmegaT Project Wizard (DGT-OT Wizard) to integrate 
DGT-OmegaT in its workflow. 


In this article, we present the workflow as used in DGT and we highlight some of the Wizard features. 


Publicold DGT-OT Guides 


/, Í Er Sendto reviser 


me Getfromreviser 
| Dome | li ! Change projea 


folders before 
| sending to 
reviser 


Confidential 
projects ENV-2016 80093000 -ENORS-00 DOCK 
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7.1. DGT-OmegaT Wizard for use outside DGT 


The DGT-OT Wizard is made available as free open-source software both as binary (for Windows) 
and as source code. The binary includes DGT-OmegaT (standard OmegaT version 3.6.0.7 + DGT 
Extensions 3.0 beta, Update 8) so that both can be installed in a single operation. 


Although it was developed to serve DGT needs in its particular context, it might also be useful for 
users outside DGT as OmegaT has only basic project management features. However, it will require 
some adaptation and not all the features will be available. 


See the Section on the DGT-OT Wizard in the DGT-OmegaT website for detailed information on how 
to install and use the DGT-OT Wizard. 


The main point is that, for use outside DGT, a setup.ini file has been added in which users can define 
the paths (either locally or on a server) in order to be able to use the Wizard — for most operations — 
in a different working environment. When the setup.ini file is saved (and the setup.cmd script is run), 
the Wizard will create automatically the folder structure (see Section 7.4). 


- An 


File Edit Format View Help 
[paths] 


: $root$ is OmegaT installation root (found by Projectwizard) 


: uncomment and change default value if necessary 


OmegaT..Home=S$root$YomegaT 

Java Home=S$rootSi java 
Dossiers=$rootS$irilesishared Dossiers 
Tradesk=$root$irilesishared Dossiers 

cd a du nl ÍA upa Sia 
TradeskLocalPath=$root$SirilesiMy. Dossiers 
OmegaTprojetsPath=Sroot$YFilesiOomegaT. Projects 
OmegaTprojetsBkpPath=S$root$SiFilesiBackup 
Revised=$root$iFilesiProjects-Revised 
ToRevise=$root$irilesiProjects-For-Revision 
;Java Home=%)AVA HOME% 


; Tradesk=server 
: Euramis=server 


[wizard] 

EuramisProject=1 

; memory usage 30 -> 100 (% of physical memory), default is 50 
OTmemuse=20 


; uncomment the following line if you will use omegaTiomegar. cmd 
| OmegaTCMD=S$root $YomegaT'omegaT. cmd 
; OmegaTCMD=C : YPGMNDGTappsCAT2017-ext'omegaT'omegaT. cmd 


Di jCS:cs-cz,DA:da-dk,DE:de-de,EL :el-gr,EN:en-gb,ES:es-es,ET:et-ee,FI:fi-fi,F 
og=none 


Helpfile=$root$YomegaTidocsYotheriDGT OMEGAT AND ITS WIZARD - Quick Guide. docx 


«| mo 


Provided the user has the necessary IT skills, the Wizard source code can be changed/adapted to 
another workflow. However, if the above structure is created and the other necessary requirements are 
met, there is no need to change the Wizard. 
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7.2. DGT workflow 


The DGT translation workflow is based on: 


1) Original documents for translation — stored in the Dossiers server (DGT translation 
repository) and managed via Tradesk, which is DGT document management application (in 
the FOSS version, the folder suggested is Shared Dossiers). 

2) Pre-processed translation memories in TMX format available in the Dossiers server in 
the relevant dossier folder under the Ypret subfolder to be used in the creation and update of 
translation projects (in the FOSS version the folder suggested is Shared TMX): 

a) From Euramis (DGT repository where aligned versions of EU legislation and 
documents translated in DGT and other EU institutions in the last 20 years are stored 
(without any formatting): 


1) Retrievals: Extraction to a TMX file of segments previously translated which 
match (65-100%) the relevant original(s) for translation; 
ii) Downloads (TMX files of full reference documents/legislation or previous 


versions/translations with a relevant match); 
lit) Extraction to a TMX file of Eur-Lex legislation titles. 
b) From MTGQEC (DGT's in-house machine translation system based on Moses): 
Machine Translation output for the relevant document(s). 

3) Projects for revision and revised, also stored in the Dossiers server and managed via 
Tradesk (in the FOSS version the folder suggested is Projects-for-Revision and Projects- 
Revised) 

4) Ongoing and finalized translations stored in the Dossiers server via Tradesk (in the 
FOSS version the folder suggested is Shared Dossiers as in point 1). 


7.3. Operations that can be performed via the DGT-OT Wizard 


The DGT-OT Wizard makes the link between Tradesk — DGT?s document management system — 
and DGT-OmegaT and allows the user to: 


a) 


b) 
c) 
d) 
e) 
f) 
g) 


Create single or multi-document projects with all the reference/retrieval/machine translation 
memories and also an IATE extraction. If the documents are in DOCX format, Tagwipe will 
clean useless tags; 

Update projects with new original documents/new versions of documents already there; 
Update projects with new memories; 

Share the project memory via TeamBase; 

Send projects for revision and get revised projects; 

Send (draft or finalized) translated documents to Tradesk; 

Send finalized document memories to Euramis. 


Furthermore, the Wizard: 


a) Does automatic backups (every 30 minutes) of the active project to a server (the personal 
space of the translator in the H: drive) in a background operation, in case there is a computer 
crash (in the FOSS version the folder suggested is Backup); 

b) Sends automatically a copy of the project memory (draft) every 30 minutes to Tradesk Ipret 
folder(s) of the relevant dossier(s) so that it can be used by another translator/reviser if 
necessary; 

c) Copies all the memories (TMX files with tags) sent to Euramis via the DGT-OT Wizard to 
the AFinal folder of the relevant dossier(s) in Tradesk for later reuse, either by a translator 
working in DGT-OmegaT or by a translator using Studio; 

d) Copies all the memories sent to Euramis (via the Wizard) to the PROJECT-MEMORIES 
subfolder of the OmegaT Projects folder to gather all the memories of finalized translations 
sent to Euramis in tmx files with tags. 


1 


Furthermore, the Wizard gathers information on OmegaT and DGT-OmegaT: in-house and standard 
OmegaT Guides, News (with a list of the changes/improvements) and a video (not available outside 
DGT). 


Users outside DGT can use the Wizard for most of operations provided that the relevant paths in the 
setup.ini file (either locally or on a server) are set and the relevant files are copied to the relevant 
folders. 


The internal DGT services — Dossier/Tradesk, Euramis, MTOEC — are replaced by simple file 
sharing. 


7.4. Folders and project structure — Differences compared to OmegaT 
7.4.1. OmegaT Projects folder structure 
When the DGT-OT Wizard is installed, it automatically creates: 


a) A folder called OmegaT Projects in which all the projects are created when using the 
Wizard. 

b) A CONFIG-PERSONAL subfolder in the OmegaT Projects folder where all the 
preferences, memorized searches and dictionaries with leamed and ignored words are stored. 
This allows to easily change them. 


logs 
script 
filtersxml 


omegat.prefs 


“| omegat.prefs-old 
[7 pt PT-ignored words.txt 
tí pt PT-learned words.txt 


search.tsv 


£ uilayoutxml 


c) A PROJECT-ARCHIVE subfolder where, just by dragging and dropping them from the 
main OmegaT Projects folder, finished projects can be stored so as not to have — over time 
— a long list of projects already finished in the main folder. 

d) A PROJECT-MEMORIES subfolder, to where the DGT-OT Wizard will automatically 
save a copy of the memories of the documents finalized with DGT-OmegaT sent to Euramis, 
thereby automatically gathering all the project memories (with tags) in a single folder. 
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7.4.2. Project folder structure 


Compared to projects created with OmegaT, the projects created with the DGT-OT Wizard have the 
differences shown in the screenshot below: 


a) 
b) 


c) 


d) 


e) 


THE DGT-OMEGAT PROJECT STRUCTURE 
when a new project Is created via the DGT-OT Wizard 


ii Monolingual or bilingue 
, dictionary dictonaryres) , if any 


d euramis 


Glossaryties) if any = If none, OT will 
create automatically a writable 
glossary for the project 


Working project memory - 
one for the whole project 


À TagNipe 
| tor 
4 tm 


Properties file created with the | | 
uralod tin it : E omega prt ta mM 
É) OS, FI-017 8018 Partnership InstrAtin-Progal 


An Amt subfolder is automatically created as DGT uses static MT provided in TMX files 
generated by its in-house Machine Translation service (MT(DEC). 

A Tagwipe subfolder is automatically created containing Tagwipe, making the application 
project-specific so that if, while translating/updating projects, Tagwipe is changed/improved, 
each project will not be affected and there will not be unduly untranslated segments. 

In the Yomegat subfolder, the segmentation rules of each project are also automatically 
made project-specific so that if, while translating/updating large projects, the segmentation 
rules are changed/improved, that particular project will not be affected (and there will be no 
unduly untranslated segments) 

The Ytmx2source and penalty-50 subfolders are automatically created to be used for the 
View Other Target Languages feature (as explained in Part 1 of this article). 

The teuramis subfolder is automatically created so that, when the individual translation 
memories of finished documents are generated to be sent to Euramis, it is in this folder that 
those files are stored. When they are sent to Euramis, the DGT-OT Wizard moves them to 
the euramisisent subfolder. Each of these memories has all the segments (with tags) of a 
particular document without orphan segments and without notes. 


7.5. TeamBase — Sharing memories in real time via the DGT-OT Wizard 


TeamBase has already been explained in Section 6 and it can be used independently. 


In this section we present briefly how it is used in DGT via the DGT-OT Wizard and how it can be 
used outside DGT after TeamBase is installed in the chosen server and the settings concerning 
TeamBase host path and password are defined. 
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Shared memories | own 


AGRI-2015-60073 
COMM-2016-00183 
COMP-FUSOES-AQUISICOES 
COMP-FUSOES-AQUISICOES-TESTE 
ENV-2016-80085-ENVIRONMENT-LAW-OBSOLETE 
ENV-2016-80088-TO-93-ECO-LABEL 
ESTAT-2016-80019 
ESTAT-2016-80019-TESTE 

-2015-01140 


OP» 2016-0061 -TESTEZ6AUG 
OP-2016-00061-TESTE-MJM2 
OP-2016-00099-BIS-TESTE 

OP-2016-00099-TESTE 

P-ENER-2016-00406-PL-RELAY 
RTD-2016-00031-GRANT-AGREEMENTS-GLOBAL 
TEST-11-RTD-2016-00031-GRANT 
TEST-5-RTD-2016-80047-SEAFLOOR 
TEST-8-RTD-2016-00031-GRANT-AGREEMENTS-GLOE 
TEST-S-RTD-2016-00031-GRANT-AGREEMENTS-GLOE 
TESTE-10-RTD-2016-GRANT 

TEST-HILARIO 
TJRC-2016-00106-RIO-COUNTRY-REPORT 
T-MJM-CA28-2016-00002-| BIOECONOMY-GREEN-GROV | 
TM-OP-2016-00060 


ENV-2016-80088+0-93-Ecolabel Read ENV-2016-8008840-93-EcoJabel 


The DGT-OT Wizard makes the use of TeamBase simple and user-friendly. To create a new 
TeamBase memory or to connect to one created by a colleague, it is just a matter of clicking on 
Teambase in the Wizard, either choosing a Teambase memory already created or accepting to create a 
new one (name is free) and selecting the desired mode (Read or Read/Write). The Wizard takes care 
of all the settings. 


To disconnect from any of the TeamBase memories the user is connected to, it is just a matter of, in 
the Wizard, clicking on TeamBase and in the middle column — Shared memories linked to my 
project — highlight the memory to be disconnected from and clicking on Disconnect From Shared. 


In the TeamBase window, in the left column are displayed the memories already created and which the 
translator can access in Read mode. 


The translator can create a TeamBase memory, stay connected all the time or connect and disconnect 
from it at any time. 


When creating a TeamBase memory the configuration settings are automatically selected without any 
action on the part of the user. 


TeamBase, when used via the Wizard, uses the Memory Mode only — i.e. a TeamBase (TMX) 
memory which is automatically created on a server and which receives a copy of the newly translated 
or changed segments of all the translators connected to it in Read/Write mode (sending segments and 
receiving segments from all the translators linked to that particular TeamBase memory). In Read 
mode the translator only receives segments from other translators. 


To be noted that, for segments already translated, only the reopened and changed segments in DGT- 
OmegaT will be sent to TeamBase when the Read/Write mode is selected. This means also that pre- 


translated segments will not be sent to Teambase either. 


When using TeamBase via the Wizard, the parameters are pre-defined and cannot be changed via the 
Wizard. 


14 


The following settings are automatically taken from the DGT-OmegaT project created via the Wizard: 


a) Project name by default (but the TeamBase memory name can be changed by the user when 
first connecting to TeamBase) 

b) Source and target languages 

c) Database host 

d) Port 

e) Database 

f) User 

g) Password 


The following settings are pre-selected and cannot be changed via the Wizard: 
a) TeamBase mode: Memory Mode 
b) Shared memory type: Free structure memory 
c) Keeping segments with same source: One per author 
d) Store properties 
These TeamBase features cannot be used via the Wizard: 
a) Project Mode 
b) Shared glossaries 
c) Inheritance 


7.6. Revision workflow 


The revision workflow for DGT-OmegaT users (both on translation and revision sides) has been 
automated via the DGT-OT Wizard. 


ENV-2016-80068-to-93-Eco-labei-GLOBAL 


The DGT-OT Wizard can be used by: 


a) The translator to easily Send to the reviser the whole project for revision or, if necessary in 
case of multi-document projects, just a part of the project documents; 

b) The translator to also Browse the project for revision — after sending it — in order to 
reorganise folders, for example, by deleting tmx files in the Ytm subfolder of the project which 
will be of no interest to the reviser; 
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c) The reviser to Get the project for revision and copy it to his/her computer and afterwards to 
Send it back to the translator for finalization (if the translator has the last word); 

d) The reviser to also Browse the revised project and reorganise it if s/he so wishes; 

e) The translator to Get the revised project to finalize it. 


Here we highlight only the sending of a project for revision as it is the step in the process which 
requires changes in the project structure/files. The other operations only require copying and renaming 
the project. 


The default, in the Send for Revision window, is to copy the project to a default server location and 
the project is automatically reorganised by copying the project memory (project save.tmx in the 
lomegat subfolder) to the tmlautoldraft subfolder of the project for revision so that the reviser — 
even if s/he changes a segment — can always see, in the Fuzzy Matches pane, the segment as 
translated by the translator with track-changes displayed. 


However, in the window that opens, the translator can choose to change any of the fields, just by 
clicking on any of them as shown in the screenshot below. 


»? Send For Revision 


ENV-2016-80088-to-93-Eco-label-GLOBAL, For-Revision-machame | 
UNCOMMONIOMEGAT-REVISIONProjects-For-Reviston 
CUsersimachameappDatalLocaNDGTOmegaT ProjectsiENV-2016-80088-10-93-Eco-label-GLOBALWomegat 


But the translator may not want to send the whole project memory, either because: 


a) In a multi-document project, only some of the documents are ready for revision; or 

b) When there are many versions of one or more documents, there may be many “orphan” 
segments (i.e., segments that were translated for previous versions but which no longer exist 
in the final document sent for revision and therefore were not carefully checked by the 
translator). 


In that case, in DGT-OmegaT, the translator can run the command Create OmegaT Export of the 
document(s) to be sent for revision. 
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UNCOMMONIOMEGAT-REVISIONIProjects-For-Revision 
CiUsersimachamelappDatalLocaNDGTiOmegaT ProjectsiENV-2016-80088-to-93-Eco-label-GLOBALlexport-omegat 
ENV-2016-80088-00-00-PT-TRA-00.DOCX tmx 


Documents to send (CTRL + click to select more) 


AS 
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